What a design system owes its users

Every design system I have seen fail did so the same way. Not with a dramatic rejection — with a slow accumulation of one-off components in feature branches, each with a reasonable justification, until the system described a product that no longer existed.

Adoption is a usability outcome

We talk about adoption as though it were a political problem, solved by mandates and audits. It is mostly a usability problem. If using the system takes longer than not using it, engineers will not use it, and they will be right not to.

The measure that matters is time-to-correct-component. If a developer needs four minutes to find out whether the thing they need exists, they will spend those four minutes writing it instead. Search, naming, and a real example per component beat any amount of governance.

Coverage is the wrong ambition

Systems chase completeness — every variant, every state, every edge — and completeness is unreachable and not especially valuable. The top twenty components carry almost all the surface area of most products. A system that does those twenty superbly and says nothing about the rest is more useful than one that does two hundred adequately.

Build the escape hatch on purpose

Teams will need to do something the system does not support. That is not a failure; it is Tuesday. The question is whether they leave the system cleanly or hack it.

Give them a documented way out: a primitive layer beneath the components, made of the same tokens. Work built on the escape hatch stays visually coherent and, crucially, stays visible — it becomes the roadmap for what to absorb next.

What it owes

Speed, honesty about its own limits, and a way to leave. Everything else is decoration.